In addition to terms defined in 3.1the following important terms are used in the description of the recipe management use case:

• Recipe object: the OPC UA data structure containing meta data for a recipe and possibly a reference to the recipe itself
• Recipe list: a list of recipe variables maintained in the VisionSystem object in the OPC UA server
• External: not part of the vision system or the OPC UA server; may refer to the automation system, the manufacturing execution system or other entities
• Environment: the set of external entities working with the vision system in one way or another, e.g. PLC, MES, etc.
• ExternalId: OPC UA datatype identifying a recipe in the view of the environment
• InternalId: OPC UA datatype identifying an instance of the recipe on the vision system
• ProductId: OPC UA datatype identifying a product in the view of the environment

Properties, procedures and parameters that describe a machine vision task for the vision system are stored in a recipe. Usually there are multiple usable recipes on a vision system. This specification provides methods for activating, loading, and saving recipes. Recipes are handled as binary objects.

Recipes are potentially complex entities. A recipe may contain (possibly nested) references to sub-recipes and it may be used for several products. The internal composition and interpretation of recipes – including the referencing of sub-recipes – is outside the scope of this specification.

Recipes are typically created and managed centrally, then rolled out to production, usually together with the information, what product(s) the recipe is to be used for, as it would not be practical to add this locally on every system.

Recipes may also be created and/or edited locally. So a local system may have additional recipes not known externally and different versions of recipes than those existing externally. This may or may not be known to the recipe management and thus to the client.

A recipe may be used for several products. Also, there may be several recipes for the same product, be it different versions of the recipe or different sub-sections of the complete recipe or different complete recipes that may be used under different circumstances.

This specification assumes that the vision system receives recipes from the environment identified by an ExternalId. Neither the vision system nor the server alter the ExternalId.

The environment uses only the ExternalId for managing recipes, and only the ExternalId or the ProductId for managing the operation of the vision system.

From the point of view of the vision system, the ExternalId identifies a recipe pushed to the system unambiguously. The vision system does not concern itself with a failure of the environment to keep the ExternalId unambiguous.

The ExternalId can achieve identifying a recipe unambiguously by using a recipe name, optionally in combination with a version number and/or a hash.

This specification distinguishes between recipes which are merely present on the vision system and prepared recipes, which have then been activated in such a way that they can be immediately used for processing.

Thus, we have two conceptually distinct operations:

• AddRecipe: Adds a new recipe to the vision system.
• PrepareRecipe: Prepares one of the recipes on the vision system. It is expected that after successful preparation, the recipe can be immediately used by a Start method for processing.

This specification assumes that the client has no knowledge of the internal recipe management by the vision system. The only information provided by the client is the ExternalId and the ProductId.

In many cases, the automation system, represented here by the OPC UA client, will want to work only with the ProductId.

This specification assumes that the client can achieve the objectives of recipe management solely by method calls.

It is therefore not required that the server exposes any recipe information beyond the objects required for the method calls in the Address Space. However, the server may choose to expose recipe information in the form of recipe metadata and references to the actual recipe contents for all recipes of the vision system or a subset thereof.

When the recipe is downloaded to the vision system via the OPC UA server, the underlying assumption is that an internal representation is created in the vision system with an InternalId that is unique in the scope of the vision system/server combination. This InternalId may comprise a hash useful for determining the binary identity of recipes.

This is especially useful in the case of recipes created or edited locally. A recipe may be locally edited. The behavior of the vision system/server combination in the case of local editing of recipes is implementation-defined. Among them (without any claim to completeness):

• The original recipe is kept and an additional recipe is added with new metadata including a new InternalId.
• The original recipe is overwritten with the edited version and the InternalId is changed to indicate the change (especially useful if it includes a hash); note that this may impair traceability in the results.
• The original recipe is overwritten by the edited version and neither the ExternalId nor the InternalId are changed; note that this will impair traceability even more severely.

The remarks on traceablity notwithstanding, the recipe management of the vision system is outside the scope of this specification and the server merely reflects the internal recipe management.

An important case – independent of the various ways of handling versions and IDs described above – is local editing of an active recipe, i.e., a recipe that is currently prepared. In effect, after the local editing, a different recipe is now active than before, so this amounts to the same as preparing a different recipe. Therefore, local editing of an active recipe shall be indicated to clients by a new RecipePreparedEvent.

When a recipe is downloaded to the vision system via the server with an already existing ExternalId and different content from the recipe already present on the system, the behavior of the vision system is again implementation-defined. Among them (without any claim to completeness):

• Keeping both the previous and the new version of the recipe under the same ExternalId with different InternalIds and employing some ambiguity resolution method to decide which recipe to use.
• Overwriting the existing recipe with the new version without changing any Ids, again impairing traceability.

Note that this specification assumes that there may be several recipes on the vision system with the same ExternalId, but different content and different InternalIds, and that it is the responsibility of the vision system to decide which one to use in a given situation.

This specification defines two methods of recipe handling:

• Method-based
• AddressSpace-based

The handling of recipes by calling methods is mandatory as it is expected to be easy to handle byclients. It uses the methods on the RecipeManagementType described in Section 0 to send/retrieve all recipe related information.

The handling of recipes in the Address Space allows for more flexibility on the part of the client as it can do its own browsing and filtering of recipes. On the other hand, it makes higher demands on client and server, and is therefore optional.

If the server offers handling of recipes in the Address Space, it will use the optional Recipes folder of the RecipeManagementType described in Section 7 to expose recipe information.

Information required by the client from the Server includes

• Recipes existing on the vision system (identified by their ExternalIds)
• The assignment between recipes on the vision system and ProductIds
• Recipes currently prepared on the vision system (identified by their ExternalIds)
• Preparedness of a particular recipe (identified by its ExternalId)
• ExternalId of the recipe to a particular ProductId

Note that the OPC UA server is merely a view on the underlying vision system. How a vendor distributes recipe and identification management between the vision system and the server is implementation-defined and outside the scope of this specification.

As long as all data required by the client is available through method calls, it is not actually necessary - although possibly desirable - to expose this information in the OPC UA server Address Space. The OPC UA server will then have to execute a vision system function to retrieve the requested information and return it in an output parameter of the method. For example, the list of recipes existing on the vision system may be requested by a client using a method like GetRecipeListFiltered instead of being read directly from the Address Space.

Exposing meta information on recipes in the Address Space has the consequence that the data is kept in two places, i.e. in the OPC UA server Address Space and in the vision system itself. In this case the implementation has to take care that the data is always updated in both places (for example by the server polling the data).

Exposing recipe information in the Address Space also allows a sophisticated client to carry out requests not covered by pre-defined methods through browsing the data on its own.

Note that sophisticated vision systems may contain a large number of recipes so that exposing the entire recipe metadata information in the Address Space may lead to a quite large Address Space.

Note, also, that this specification does not require the server to expose this information and that the client thus cannot rely on the information being present nor on it being complete as it may cover only a subset of existing recipes, e.g. the list of currently prepared recipes.

To illustrate the above remarks on recipe management, here is a possible life cycle of a recipe: Note that the method signatures are not necessarily exact here.

1. A recipe for ProductId-m is created externally (often centrally).
2. The recipe is pushed to the vision system with ExternalId-1, ProductId-m using AddRecipe

It is stored there with ExternalId-1, InternalId-11.

It is linked to ProductId-m on the vision system.

There are further possible actions on the recipe without any particular order.

The recipe may be edited locally later, keeping its ExternalId-1 and receiving InternalId-12.

A (binary) different version of the recipe with the same ExternalId-1 may be pushed to the vision system later, receiving InternalId-13.

The recipe may be linked later to ProductId-n on the vision system Note that the external recipe management does not concern itself with the InternalIds of the recipes on different vision systems. If there are, due to one of these operations, several recipes on the vision system with identical ExternalIds but different InternalIds, the vision system/server combination has no means of telling which of these was targeted by the environment. It may choose to link all of them, or the newest one, or the latest one pushed (ignoring internally edited ones). This is outside the scope of this specification.

The automation system is undergoing a change-over process to a specific product, namely ProductId-m. It will re-tool the vision system

by calling PrepareRecipe on ExternalId-1); the vision system then selects one of the existing recipes with ExternalId-1 based on its internal rules.

by calling PrepareRecipe on ProductId-m; the vision system then selects one of the existing recipes linked to ProductId-m based on its internal rules.

The vision system is commanded to process a specific product

by calling a Start… method with ExternalId-1 the vision system then starts processing with the recipe prepared for ExternalId-1.

by calling a Start… method with ProductId-m the vision system then starts processing with the recipe prepared for ProductId-m.

by calling a Start… method with ExternalId-2 the vision system then throws an error because no such recipe has been added or prepared.

by calling a Start… method with ProductId-p the vision system then throws an error because no such recipe has been added or prepared.

If there is no error, the vision system carries out its task, going through the Executing state to return tostate Ready waiting for further instructions.

There are many other possibilities of errors, e.g. trying to prepare a recipe which is actually a sub-recipe, i.e., not capable of being processed by itself.

Note that the capabilities of systems with respect to recipe management may be very different. In the following typical system setups are described without any claim to completeness. Note also that the behavior described is only one of several possibilities.

• Preconfigured system: a system that is configured outside the scope of this specification, starts automatically through states Preoperational and Initialized into Ready. It will immediately react to Start method, ignoring a possible recipe or product argument.
• Single recipe system: a system that can hold a single recipe; it may start through Preoperational into Initialized, then wait for a call to the AddRecipe method and immediately prepare this recipe and transition into Ready. It can immediately react to a Start method call, ignoring a possible recipe or product argument (or it will throw an error if this is not the current recipe/product).
• Single program system: a system that can hold several recipes but can have only a single prepared or active recipe; it starts through Preoperational into Initialized, then waits for one or more AddRecipe method calls, staying in Initialized. Upon a call to the PrepareRecipe method it will transition into Ready. It will immediately react to a Start method call with the appropriate recipe or product argument, but throw an error if this is not the prepared recipe/product.
• Multi program system: a system that can hold several recipes active; it behaves like a single program system until Ready. It will then allow for several additional recipes to be prepared (state handling is discussed later). For each of the prepared recipes, it will react to a Start method call immediately if the recipe or product is prepared and throw an error for a not-prepared recipe or product.

Note that all transitions are under the provision that no error occurs.

The following explanation relates to the VisionAutomaticModeStateMachine described in Section 8.3. Vendor-specific mode state machines may behave differently.

Note that preparing a recipe may be an operation of considerable complexity taking a significant amount of time. During that time the system may or may not be capable of reacting to a start method. Some recipes may exclude each other from being prepared at the same time, for example, when there are mechanical movements involved. Having two such recipes prepared at the same time would mean that an instantaneous reaction to a Start method call for a prepared recipe would not be possible. However, this is at the discretion of the vision system. The client may merely notice an unusually long reaction time between calling the Start method and the actual state change, or the vision system may prevent the simultaneous preparation by returning an error.

Independent from the system types mentioned in the previous section, (with the exception of the Preconfigured System, for obvious reasons) is the capability of preparing a recipe in the background. This refers to the situation where PrepareRecipe has been called, the method has returned, but the preparation of the recipe is not yet finished. A system may stay in state Ready and react correctly to the previously prepared recipe or a different prepared recipe.

The server is free to handle PrepareRecipe as a synchronous method, i.e., when it returns it is assumed that the recipe in question is completely prepared and the IsCompleted output variable must be set to TRUE unless an error occurred.

Since recipe management is outside the scope of this specification and solely the province of the vision system itself, the server is entitled to any reaction that fits the internal recipe handling of the vision system. That means that calling the AddRecipe or PrepareRecipe methods in Ready state may result in

• the system falling back into state Initialized, then returning automatically to state Ready, or (in the case of AddRecipe) waiting for PrepareRecipe. What recipe is then prepared is system-dependent; the client can use the GetRecipeListFiltered method with an appropriate filter to determine that.
• the system staying in Ready state but returning an error when the client tries to call a Start method on the recipe

Thus, vision systems may behave in different ways, depending on their recipe management capabilities, and therefore exhibit different transitions for calls to the AddRecipe and PrepareRecipe methods. These variations are difficult to depict graphically; therefore, the state machine diagram shows those transition causes assumed to be typical.

It follows that the client cannot assume to be able to trigger a particular transition by calling one of these methods. Without a priori knowledge about the behavior of the vision system/server combination, the only way for the client to actually force a return to the Initialized state is by going through Preoperational state via a reset. It must be prepared however that the vision system may fall back to Initialized state upon any call to AddRecipe or PrepareRecipe methods, even depending on the recipe itself (e.g. when it requires to initialize or check for additional hardware for a particular recipe).

The client therefore should not actually be interested in the transition, but only in two questions:

• Is the system Ready?
• Is the recipe/product to be started already prepared?

There are two possibilities to handle the situation of a preconfigured system not having any recipe management capabilities:

• Set the Executable flags of the methods permanently to false.
• Omit the methods completely.

It is recommended to use the second method as this makes the capabilities of the system much clearer to a (generic) client. Therefore, recipe management methods are optional in this specification.

A client should nevertheless always check the executability of a recipe management method before calling it since, depending on the state of the vision system, any of these methods may not be executable under certain circumstances.

The basic idea of the operation of a vision system underlying this specification is using it for the inspection of particular products with settings contained in a recipe related to this product. Thus, there is a relationship between recipes and products. It may be an n:m relationship, meaning that one recipe can potentially be used for more than one product and that there may be more than one recipe for a specific product, e.g. depending on the circumstances of use.

The relationship between recipes and products will typically not be fixed or predefined as the set of available recipes and products to be processed will change over time. Therefore, some means must exist to establish links between products and recipes.

This specification uses different parameter combinations of the AddRecipe method of the RecipeManagementType to achieve the linking between recipes and products in the method-based approach and a LinkProduct method of the RecipeType in the address-space-based approach.

In the purely method-based approach, these links are only stored within the vision system and can be retrieved indirectly through the GetRecipeListFiltered method with appropriate filter settings.

In the address-space-based approach, the products a recipe is linked to are stored as a list within the RecipeType.

This specification defines two fundamental methods of exchanging the actual recipe content between the client and the server/vision system combination, depending on whether the server exposes recipe information in the Address Space or not.

As stated in Section B.1.3.3, Recipes in the , the RecipeManagementType has mandatory methods which allow for the management of recipes by the client, including data transfer of the recipe content in both directions.

In principle, this works as follows:

1. The client either creates a recipe entry with a new ExternalId on the vision system (using the AddRecipe method) or retrieves existing ExternalIds using the GetRecipeListFiltered or similar method and selects one of these.
2. The client uses the new or selected ExternalId in the generateOptions of the call to GenerateFileForRead or GenerateFileForWrite method of the RecipeTransferType component of the RecipeManagementType object to create a temporary file object for the transfer.
3. The client uses the NodeId and FileHandle of the created temporary file object to call its Read and Write methods to transfer the recipe content.
4. The client uses the Close or CloseAndCommit methods of the temporary file object to end the data transfer and close the temporary file object.

Note that this does not imply that the recipe is actually represented as a single file. In what way the vision system/server component uses and persists the transmitted data is implementation-defined.

For a recipe exposed in the Address Space as an entry in the optional Recipes folder of the RecipeManagementType object, the client can perform the data transfer as follows:

1. The client browses through the Recipes folder to find the recipe with the desired ExternalId, or it uses the AddRecipe method to create a new recipe entry and uses the returned NodeId.
2. It uses Open method of the FileType component of the detected Recipe object to open the pertaining file object for reading or writing.
3. It uses the Read and Write methods of said component to transfer the data.
4. It uses the Close method of said component to end the data transfer.

Note that this does not imply that the recipe is actually represented as a single file. In what way the vision system/server component uses and persists the transmitted data is implementation-defined.